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Last time, we saw how adding dynamic binding to in- 
heritance allows old code to call new code. By using dy- 
namic binding, the same method call on various objects 
takes on various meanings. ‘This idea, of one method call 
having “many forms”, is known as polymorphism. 

However, it is very important that the specification of 
the superclass method is also correctly implemented by 
the method of the new subclass. ‘This is because the 
older code that used superclass references and called su- 
perclass methods believed the superclass methods would 
accomplish certain things. If you now come along with 
a subclass method that overwrites a superclass method, 
but that subclass method doesn’t do what the specifi- 
cation of the superclass method said it would do, then 
the real task that the subclass method accomplishes isn’t 
the task the initial programmer had in mind when he or 
she wrote the initial superclass-reference- and-superclass- 
method-calls code. 

So, if the superclass method specification says “Draw () 
draws object to screen”, all the subclasses that imple- 
ment their own version of Draw() must follow that spec- 
ification and have their version of Draw() draw them to 
the screen. If the superclass method specification says 
“Scale(xFac, yFac) makes the object xFac-times larger 
in the x direction and yFac times larger in the y direc- 
tion” then all subclass objects must scale themselves ac- 
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cordingly when they overwrite Scale(x, y). This can 
cause problems, for example, if we try to have a class 
Circle extend a class Ellipse, because even though 
the superclass (Ellipse) can scale in different amounts 
in different directions, when we try to implement that in 
the subclass, Circle, we find that if we scale the Circle 
to different amounts in the x and y directions, we no 
longer have a circle!!! (Imagine stretching a circle twice 
as long horizontally, but three times as long vertically. It 
would be an ellipse, not a circle!) 

This suggests that, if Ellipse has a Scale(xFac, 
yFac) method where xFac and yFac can be different, 
and if we don’t want deformed circles, then we cannot 
have Circle inherit from Ellipse. This is because we 
could have written the following code before adding the 
subclass class Circle: 


Ellipse el; 
e1 = ReturnEllipseOrSubclass() ; 
e1.Scale(2, 3); 


and if ReturnE1llipseOrSubclass() returns an Ellipse 
object, we expect a scale of twice-as-large horizontally 
and three-times-as-large vertically. But, then if we add 
the subclass Circle and try to write Circle’s Scale(x, 
y) to assume that x and y must be the same, or to do 
nothing, or to do something else to keep the method from 


deforming Circle objects, then the above code will not 
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work as the original programmer expected if e1 happens 
to point to a Circle object. But, that was the whole 
point of all this — that the original programmer can write 
the above code and know that future subclasses will not 
keep it from working as expected. 

This is a complex issue that we will also look at more 
in C$225. For now, the key is to understand that proper 
inheritance is about substitutability. It doesn’t matter 
that a circle is a more specific kind of ellipse. You need 
circle to be substitutable for an ellipse. So, if you un- 
derstand that subclass objects should be defined to be 
substitutable for superclass objects — meaning they sup- 
port all the functionality the superclass had — then you 
will be fine. 





Abstract methods and abstract classes 


Abstract classes are classes where one or more method 
definitions are missing — we have the name but no defi- 
nition. Such methods are known as abstract methods. 
We cannot allocate objects whose types are abstract classes, 
because some method defintions (specifically, the defini- 
tions of the abstract methods) are missing! It would be 
like building a house from a blueprint when someone cut 
a big hole in the blueprint and stole the description of 
how to build the living room. 

With abstract methods, you can create an abstract in- 
terface for a large hierarchy of classes, and then imple- 
ment that interface with specific subclasses. 


public abstract class Shape 


{ 

public Shape() 

{ 

// whatever needs doing 

t 

public abstract void Draw() ; 

public abstract float Area(); 

public abstract float Perimeter () ; 

public abstract int NumSides() ; 
t 

Now 


e we can’t create objects of type Shape 
e we can’t create objects of Shape’s subclasses unless 


those subclasses implement all abstract methods. If 
they don’t, they are abstract themselves. 


public class Circle extends Shape 


A 


float centerX, centerY; 
float radius; 


public Circle() 


{ 
super () ; 
// whatever needs doing 
t 
public void Draw() 
{ 
System.out.print("Drawing a circle at point" 
eae We Ae) 
t 
public float Area() 
{ 
return radius * radius * 3.14; 
t 


public float Perimeter () ; 
{ 


return 2 * 3.14 * radius; 


} 


public int NumSides() 
{ 


return 1; 


- 


So, we can still have Shape references and we can still 
invoke Shape methods off of them. 


public static Shape ReturnObject() 


{ 
// code to return a Shape reference 
// that will be pointing to some 
// object of Shape (which we actually 
// can’t do) or a subclass of 
// Shape (which we *can* do if that 
// subclass implements all the abstract 
// methods of Shape. 

t 

Shape s1; 

si = ReturnObject() ; 

si.DrawQ) ; 


It is just that, while ReturnObject() returns a Shape 
reference, that reference can only refer to an object whose 
type is a subclass of Shape. Before, we had the option 
of also returning an actual Shape object, and that’s the 
only thing we've prevented ourselves from doing. 

This idea of abstract classes is helpful when you have 
methods you want an entire hierarchy to use (such as 
Draw() and so you want the idea of a superclass reference 
and a method name in the superclass so that the two can 
be matched at compile-time....but when, in addition, you 
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also have no real good way to define what that method 
means in the most general case of your superclass. (What 
does “Draw()” mean for a Shape? We don’t even know 
what shape it is!) How can we possibly draw it’) 

In such a case, you use abstract classes. Since method 
names are matched to reference types at compile-time, 
you make sure your highest-level superclass has all the 
method names you need. But since method definitions 
are matched to object types (which we don’t necessarily 
know until run-time) then as long as you prevent the 
allocation of abstract class objects, you will never actually 
need the defintion of that method for your abstract class, 
since there will never be an abstract class object to match 
that (missing) definition to. 

In large system design, you figure out the general classes 
in the problem domain — for example, “department re- 
port” — and write the system so that the interface of those 
classes is well-thought out and all parts of the system can 
interact with each other through those abstract interfaces 
of the highest-level superclasses. ‘Then, once that frame- 
work is in place and all these abstract classes are talking 
to each other, you then write the subclasses that imple- 
ment those abstract class methods (“accounting depart- 
ment report”, “engineering department report”, etc.) and 
the concrete methods you write will have their definitions 
bound to the abstract method names you wrote earlier. 
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And then when the abstract classes are talking to each 
other, it is really your choice of subclasses talking to each 
other via dynamic binding. And you can swap out one 
subclass of an abstract class, and swap in another one, 
and all the pre-existing code still works correctly (due to 
dynamic binding and correct design) and the system goes 
on as always. 

But we cannot write the best possible abstract classes 
unless we understand the problem domain well — which is 
why when you work for a company and are writing a new 
software system for a client, you (or whoever designs the 
system) often spend a lot of time with the client initially, 
trying to understand their business, so that you get a 
good feel for what the major ideas are for this problem 
domain and how you can best write your new software 
package for them in a general manner. 

This is an issue you will study further in later courses 
and gain more experience with, with but this is your in- 
troduction for now. Inheritance — through the use of ab- 
stract classes and dynamic binding — is a powerful tool 
that allows us to write code that is very easily extended 
to provide new features. 





One last point... 


In Java, all classes are subclasses of Object, which has 
methods such as toString() and equals(). So, there 
are certain things you can do for all objects. If you don’t 
use extends... then you are automatically extending 
Object. 


